@AenBleidd I have fixed a few issues in the Mac build scripts and updated the Mac build instructions. The local build seems to work correctly on my Mac. If it works correctly for the CI build, then I think it is ready from my point of view.

@CharlieFenton, thank you for your fixes.
I will wait for a new release of fmtlib that contains fixes for x86 builds, and then we will be reado for the merge.

@AenBleidd : 2 questions.

[1] Do you expect to use libfmt mainly in the Manager? If so, I can update the Xcode project to link it to the Manager and add the headers to the header search path. Should i do that?

[2] The Mac Manager uses a precompiled prefix header clientgui/mac/MacGUI.pch which includes all the wxWidgets headers, config.h and stdlib.h plus a few other items. If we expect to use libfmt widely (like we now use stdlib) I could add the #include fmt/format.h to this file. But that only makes sense if there is a corresponding way to do it for Windows and Linux builds. If those require adding the #include fmt/format.h to the individual .cpp files, then nothing is to be gained from putting it in the precompiled header for the Mac.
Should I add the #include fmt/format.h to clientgui/mac/MacGUI.pch?

@CharlieFenton,

Do you expect to use libfmt mainly in the Manager?

I would like to use it everywhere since it's more comfortable and more powerfull with the better and simpler syntax.
But I definitely don't want to start refactoring just to switch to this library.
We were talking with David recently about this, and his idea was to start using this library in the docker_wrapper first (since this is the component we are extensively working on during the last sveral months).
So I would not add fmtlib globally and instead do that when time comes.
Of course, if you want to do that in advance - feel free to do that.
However, I believe, doint this now will make the whole building process a little bit longer because it will be trying to link the library that is not used in aone or another prohect (and eventually will not do that since there is no any symbols imported from that library) .

Should I add the #include fmt/format.h to clientgui/mac/MacGUI.pch?

The answer is basically the same: I would not do that unless we start using it in more that one file.
For Windows we do use precompiled headers (they are not unified at the moment, but this is something I fix later, since currently it works and is not a big time loss during the compilation phase).
For Linux we do not using precompiled headers at all, but this is something I plan to fix.

So just to summarize: I would not include it into the list of precompiled headers and would not include this library by default until we start using it actively.

In general, .h files should be included only in files that directly use them

@davidpanderson, yes, but if any external header file is heavily used across several files - having it precompiled will significantly lower compilation time.
This is expecially applicable to those libraries that use heavy templates (e.g. nlohmann-json, fmtlib, etc).